home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 1952 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.1 KB
  1. Path: diku.dk!null
  2. From: null@diku.dk (Niels Ull Jacobsen)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: C++ performance
  5. Date: 14 Jan 1996 13:26:31 GMT
  6. Organization: Department of Computer Science, U of Copenhagen
  7. Sender: null@tyr.diku.dk
  8. Message-ID: <4db0a7$60d@odin.diku.dk>
  9. References: <4d3v93$rf9@news1.usa.pipeline.com>
  10. NNTP-Posting-Host: odin.diku.dk
  11. X-Newsreader: NN version 6.5.0 #13
  12.  
  13. grantp@usa.pipeline.com(Pete) writes:
  14.  
  15. >On Jan 11, 1996 18:25:17 in article <C++ performance>,
  16. >'christ@lexis-nexis.com (Chris Tilton)' wrote: 
  17. > 
  18. > 
  19. >>What (if any) rules of thumb/tricks of the trade exist 
  20. >>for enhancing the performance of a program?  I discovered 
  21. >>how to make a small function 'inline' and was curious 
  22. >>of what else exists to enhance execution speed.   
  23.  
  24. /O2   :-)
  25.  
  26. >The best rule of thumb is to analyze your algorithms and improve 
  27. >them to the best of your ability.  Use a profiler to help determine 
  28. >where your program spends most of its time and concentrate on 
  29. >speeding up those portions.  Inlining and other 'tricks' applied 
  30. >everywhere without discretion typically produce only minor gains. 
  31.  
  32. This is, of course, the best advice.
  33.  
  34. Another typical pitfall of C++ is accidently invoking copy
  35. constructors.  *Always* implement a copy constructor in your objects,
  36. unless you *really* want the default one. If you make it private, your
  37. compiler will tell you most of the time when you accidently invoke
  38. it. If you leave out the implementation, your linker will tell you the
  39. rest.
  40.  
  41. In some environments, it will pay to make large local variables static
  42. (unless you're worried about reentrancy, of course).
  43.  
  44. Also, once you have found the *really* time-critical pieces of code,
  45. turn on the "assembly listing" option of your compiler and try to
  46. figure out what is really going on. Sometimes you'll be amazed.
  47.  
  48. But go for the algorithms first. One can waste a lot of time studying
  49. assembler listings and hand-tuning procedures to gain 10% instead of
  50. improving the algortihm to gain 50%.
  51.  
  52. > 
  53. >-- 
  54. > 
  55. >Pete
  56. -- 
  57.    Niels Ull Jacobsen, Dep. of CS, U of Copenhagen (null@diku.dk)
  58.    Roenne Alle 3 st.th, 2860 Soeborg, Denmark, tel. +45 39 66 39 86
  59.  
  60.